Your PR requires formatting changes to meet the project's style guidelines.
Please consider running Runic (git runic master) to apply these changes.

diff --git a/perf/array.jl b/perf/array.jl
index 3dbab9816..400de2231 100644
--- a/perf/array.jl
+++ b/perf/array.jl
@@ -54,11 +54,11 @@ let group = addgroup!(group, "reverse")
     group["1d"] = @async_benchmarkable reverse($gpu_vec)
     group["1dL"] = @async_benchmarkable reverse($gpu_vec_long)
     group["2d"] = @async_benchmarkable reverse($gpu_mat; dims=1)
-    group["2dL"] = @async_benchmarkable reverse($gpu_mat_long; dims=1)
+    group["2dL"] = @async_benchmarkable reverse($gpu_mat_long; dims = 1)
     group["1d_inplace"] = @async_benchmarkable reverse!($gpu_vec)
     group["1dL_inplace"] = @async_benchmarkable reverse!($gpu_vec_long)
     group["2d_inplace"] = @async_benchmarkable reverse!($gpu_mat; dims=1)
-    group["2dL_inplace"] = @async_benchmarkable reverse!($gpu_mat_long; dims=2)
+    group["2dL_inplace"] = @async_benchmarkable reverse!($gpu_mat_long; dims = 2)
 end
 
 group["broadcast"] = @async_benchmarkable $gpu_mat .= 0f0
diff --git a/test/runtests.jl b/test/runtests.jl
index b6c479cce..89bf840c9 100644
--- a/test/runtests.jl
+++ b/test/runtests.jl
@@ -5,7 +5,7 @@ using Printf: @sprintf
 using Base.Filesystem: path_separator
 
 using Pkg
-Pkg.add(url="https://github.com/christiangnrd/GPUArrays.jl", rev="accumulatetests")
+Pkg.add(url = "https://github.com/christiangnrd/GPUArrays.jl", rev = "accumulatetests")
 
 # parse some command-line arguments
 function extract_flag!(args, flag, default=nothing; typ=typeof(default))

Well, that's a bit all over the place.

Well, that's a bit all over the place.

Indeed..

Hacking in the big mapreduce kernel heuristic for the by-threads or by-block decision into AK we recover most of the performance discrepancy. It's still a regression, but on a 3090 the Int64/dims=1 ratio is 7.3 for AK/master, and 1.7 for (AK with better heuristic)/master. For Float32/dims=1 the ratios are 6.1 and 1.2 respectively. Still need to figure out what's happening with dims=2L, but at least the performance discrepancy won't be as bad once JuliaGPU/KernelAbstractions.jl#631 is figured out and implemented in AK.

1.7 for (AK with better heuristic)/master

That's too bad, and very much at odds with the results I've seen presented on AK.jl at e.g. JuliaCon. I guess the reduction kernel wasn't really optimized properly yet (the paper seems to focus on sorting operations).

I guess the reduction kernel wasn't really optimized properly yet

I suspect the dims=2L case could be mitigated by a better heuristic for determining block size than always 256. That test is quite the weird shape and there's a huge improvement with greater block sizes

@christiangnrd do you think it's worthwhile to open an issue at AK.jl about this (if one isn't open already)?

@christiangnrd do you think it's worthwhile to open an issue at AK.jl about this (if one isn't open already)?

Good idea. I opened #60

Do I read this correctly?

For accumulate:

• 1d is faster (0.51 / 0.64).
• Nd is faster for one dim but slower on the other; this might be something to improve on switching between the by-thread and by-block algorithms.

In the other PR (#2815) for mapreduce:

• 1d is comparable
• Nd is much slower for the L cases; faster for one dim but slower on the other otherwise.

This is the same trend as the timings I posted when first implementing N-dimensional reductions (JuliaGPU/AcceleratedKernels.jl#6 (comment)); AK-0.1 didn't have dims :)

@christiangnrd is right, we should definitely improve the heuristic for switching between the by-thread and by-block algorithms. For the innermost reduction kernel though the CUDA.jl algorithm should be superior, and until we have warp sizes and shuffle instructions exposed in KernelAbstractions I don't think we can do much better (implementation and notes here). What is better (and original afaik) in the AK mapreduce is not doing recursive memory allocations when needing multiple kernel launches (switching views into different ends of the same vector here) - memory consumption is bounded and known upfront.

I'll use the L cases for Nd mapreduce to investigate bottlenecks...